Introduction to Explicit Neutral Models

This notebook illustrates how you can use PMD to optimize network models with an explicit neutral (EN) conductor representation. It will go through the full workflow, consisting of

• importing OpenDSS network data (and applying transformations as needed);

• adding OPF-specific data to the model;

• optimizing the model;

• inspecting the results.

This notebook will make use of the following packages in various places

Building a case

Importing network data

OpenDSS cases with explicit neutral conductors tend to use components in a way which is not supported directly by PMD. These cases model the grounding as a 'reactor', connected between different terminals of the same bus (i.e. from the 4th terminal to ground).

In PMD, a reactor is mapped by default to a line, which will then be connected on both ends to the same bus, which is not allowed. This problem is solved by applying the data model transformation transform_loops!, which will map the reactor to a shunt instead, or merge terminals if the reactor is in fact a short-circuit.

Note that this test case is very unbalanced. To obtain a more realistic scenario, we reduce the loading by a factor 3.

Adding OPF specific data

First of all, it is a good practice to remove any bounds that may have been imported from the OpenDSS network data. These can be default bounds, which might not make sense for the specific case and can lead to infeasibility. For example, this occurs for IEEE13, where the default OpenDSS line ratings are too tight for the base case power flows.

Voltage bounds

Voltage bounds are naturally expressed between two terminals.

For example, if a wye-connected load is connected between phase a and the neutral n, we want to apply the bounds lb <= |Ua-Un| <= ub, in order to ensure the voltage across the load does not get too low or high. If the neutral is not modeled and assumed to be grounded everywhere, i.e. Un=0, then this can be done equivalently by bounding Ua directtly.

PMD comes with several data model transformations which allow you to quickly apply voltage bounds. The bounds are specified in per unit, relative to the local voltage base (phase-to-ground). If this was not the case, it would be difficult to specify bounds for multiple voltage zones at once.

First consider add_bus_absolute_vbounds!, which allows you to specify absolute bounds, i.e. for each terminal individually. This will set the bus properties vm_lb and vm_ub appropriately.

The ENGINEERING data model includes special properties to easily apply symmetrical bounds for three-phase buses (refer to the documentation for more details). These properties can be populated easily with add_bus_pn_pp_ng_vbounds!, which specifies

• phase-to-neutral (pn)

• phase-to-phase (pp)

• neutral-to-ground (ng)

bounds. Note that since the voltage base is in phase-to-ground, the pp bounds have to multiplied by sqrt(3) for a three-phase network.

Often, the true goal of voltage bounds is to protect the connected 'units', i.e. loads, generators etc. Therefore, it can suffice to apply voltage bounds only to those buses and terminals which actually have a unit connected to them. This is what add_unit_vbounds! is for. The delta_multiplier is the correction factor which is applied to the specified bounds if a unit has configuration=DELTA.

Whether it is desirable to apply as many bounds as possible, or only ones which are really needed, will depend on the chosen formulation later on. In any case, these data model transformations make it easy for the user to apply any desired bounds.

You might have noticed that applying all these transformations will lead to redundant constraints. This is resolved in the data model transformation, which determines a set of absolute and pairwise voltage constraints which imply all other ones.

For example, let's inspect bus b2. This bus has a single-phase load between terminals 1 and 4, so only for that pair the lower bound should be 0.91 instead of 0.9. For an explanation of how the vm_pair_lb property is structured, refer to the documentation.

Adding a generator

So far, we imported a power flow case from OpenDSS. This means that the problem is fully determined, i.e. there is no degrees of freedom left over which to optimize. Therefore, we will add an additional generator to the problem.

Solving a simple OPF problem

First of all, we apply the data model transformation to go from ENGINEERING to MATHEMATICAL. We need to pass the flags kron_reduce=false and phase_project=false; these activate data model modifications which are required for some formulations, but not for the EN ones.

Before solving the problem, it is important to add initialization values for the voltage variables. Failing to do so will almost always result in solver issues.

For a single-phase equivalent network, this is very easy to do; simply initialize each voltage variable to 1.0+im*0.0, which usually corresponds to the voltage profile without any network load and ignoring all shunts and linecharging (refered to as 'no-load voltage').

The equivalent in a general, multi-conductor network is less trivial; for example, transformers can shift the no-load voltage angle of individual terminals in complicated ways. Therefore, we developed the method add_start_vrvi!, which will infer the no-load voltage for each terminal in the network and add initialization properties to the MATHEMATICAL data model.

Now we are ready to solve the OPF problem.

Inspecting results

The result dictionary contains the solutions.

Next, we can transform the solution back to the ENGINEERING data model.

For example, let's inspect the dispatched active generator power.

The active generator power bounds are not active, 0 <= 5.15 <= 10.0. This means some other bound is active, because since g1 has zero cost, it is normally more optimal to dispatch more active power, which the source bus generator will pay the default price for.

So, let's inspect the voltage at bus b2. We will obtain the voltage base through 'data_math', which will allow us to inspect the voltage in pu. This will make it easier to compare the values against the bounds we specified before.

As it turns out, the voltage magnitude constraint om the neutral terminal is binding, vm_b2_pu[4]=0.1.

Available formulations

We create a results dictionary which will collect the result dictionary generated by each formulation. We will end this section with a comparison of them.

There are several formulations available which support explicit neutrals. The main distinction is whether the flow variables are current or power variables.

Current flow variables

The preferred class of exact formulations are IVR, i.e. with current flow variables (I) and rectangular voltage variables (VR).

IVRENPowerModel is a non-linear formulation.

IVRQuadraticENPowerModel is an equivalent quadratic formulation.

Reduced models only create explicit series current variables, and create the total current variables as linear expressions of those. Since branches tend to be the dominate component in number, this can lead to a big reduction in the number of variables.

IVRReducedENPowerModel is the branch-reduced version of IVRENPowerModel.

IVRReducedQuadraticENPowerModel is the branch-reduced version of IVRQuadraticENPowerModel.

Power flow variables

We also included a single formulation with power flow variables. Because it also has rectangular voltage variables and legacy reasons, it is referred to as ACRENPowerModel.